1. Field of the Invention
This invention relates to the field of debugging compiled computer languages and, in particular, to methods, computer program products, and hardware products for handling breakpoints in an asynchronous debug model.
2. Description of Background
In a debugger for compiled languages, it is common to implement a location breakpoint, such as a source line, a code address, or a function entry point, by substituting a machine instruction that causes a trap for the machine instruction at the breakpoint location. Modern architectures usually make the process of implementing a location breakpoint quite simple by providing an instruction specifically for this purpose. When an application being debugged reaches the trap instruction, the debugger receives a signal. If the debugger needs to restart the application, the debugger must perform the following sequence of operations, herein referred to as a “hop”: (1) replace an original instruction; (2) make the application step one instruction (machine step); and (3) replace the trap instruction.
The foregoing procedure works well if the application has only one thread of execution. If the application has multiple threads, the simple implementation of this procedure could result in another thread running through the location while the breakpoint is removed. One possible solution is to prevent the other threads from executing while the trap is removed. However, a problem occurs when the debugger is run in an asynchronous debug mode. In a synchronous debugger, all threads are stopped when any thread stops. By contrast, in an asynchronous debugger, only the thread that has the debug event stops. Various solutions exist for addressing the problems of preventing threads from executing and of restarting only a subset of the threads of the application after a debug event occurs. These problems must be solved if one is to construct a debugger for multithreaded applications. A significant problem may occur if many threads are stopped at locations that contain breakpoints and the debugger needs to restart two or more of these threads. This scenario is common in situations where one is attempting to debug the parallel code in an application that uses a technology such as Open Multi-Processing (OpenMP). OpenMP, discussed herein solely for purposes of illustration, is an application programming interface (API) that supports multi-platform shared memory multiprocessing programming in C/C++ and Fortran on many architectures, including Unix™ and Microsoft Windows™ platforms. OpenMP includes a set of compiler directives, library routines, and environment variables that influence run-time behavior. Another illustrative environment is Unified Parallel C (UPC).
If the breakpoint is in a loop, it is undesirable for the debugger to cause any of the threads in the application to “hog” the CPU. If one simply hops off the breakpoint and then allows the thread to run, it is very likely that the same thread will return to the breakpoint before any of the other threads can be started.